disclosure / definition of "patch"
James R. Ault (ault@cs.albany.edu)
Thu, 01 Dec 1994 17:36:37 EST
> Surely there is a third way: time-lapsed full disclosure. When a problem is
> discovered, don't announce it until there's a patch, then announce
> the problem and the patch together, without exploitation information.
But there's one other problem here: Depending on the definition of
"patch" and "exploitation information", this could be describing both
CERT and 8lgm.
Does a "patch" have to come from a vendor? or does a drop-in replacement
from bugtraq qualify as a "patch"?
CERT doesn't announce it until there's a patch _from the VENDOR_, and
there is no exploitation info to make the vendor hurry at all, so they dont.
CERT also probably considers the phrase "binmail uses tempfiles that
are created unsafely" as exploit information, while most of us on
bugtraq don't.
I was very grateful for the mail.local replacement that was posted to
bugtraq, and I installed it, and I am convincing others to install it
also.
This often comes down to philosophy. Some sites prefer to install
only vendor code and patches, some are willing to replace pieces, some
run a completely free OS anyway. There is a wide difference between
those who do/don't care about security, _and_ those who have or make
time to deal with it.
So, when you advocate a stepwise approach: make it clear that any
_workaround_ whether it is a replacement program or a chmod command or a
vendor patch would be an acceptable fix. "patch" needs to be more
clearly defined. CERT waiting for the vendors is what makes them take
so long.
I much prefer a workaround like mail.local from bugtraq, but it comes
down to who you decide to trust...
Jim Ault, CS Sysadmin, SUNY Albany, NY 12222 USA ault@cs.albany.edu <><